Electronics designers commonly rely on simulators and emulators to test their designs for both operability and compatibility with existing systems or interfacing components. A simulator typically comprises a general purpose computer workstation that runs a simulation program. The program uses software to simulate, or model, the circuits of the design to be evaluated. The program thus simulates input signals and outputs data representative of signals produced by the circuits in response to the input signals.
Simulators by themselves, however, have been found to be relatively inefficient and lacking in processor speed, particularly for large and complex designs, and can require prohibitively long periods of time to complete a simulation. To help alleviate these limitations, accelerator hardware can be interfaced with a workstation. An accelerator is typically an electronic circuit board system that performs the concurrent processing, or operations that model circuit logic. The workstation can then concentrate the majority of its available processing power on sequential operations, i.e., operations that apply test vector data and otherwise simulate sequentially occurring activities with respect to a simulation.
A further improvement in processing efficiency can be gained by providing an emulator, or an emulator/accelerator combination. An emulator is a large scale hardware configuration typically implemented in field programmable gate arrays (FPGAs) or some other type of software configurable custom hardware. Because the logic is modeled in hardware (e.g., FPGAs) that approaches the same degree of parallel operation that the actual circuit being modeled would exhibit, the emulator/accelerator can perform the concurrent operations much faster than an accelerator alone.
Emulator are capable of emulating many types of computer system hardware and other logic, including, for example, memory devices. One emulator type, for example, executes a logic model embodied in suitable software that reflects a combination of a user model logic portion and non-user-model logic portion. The user model logic portion may be derived from (e.g., compiling) a netlist for the hardware design under test. Accordingly, this portion represents the functionality of the hardware design. The non-user-model logic portion is peripheral to the hardware design itself and is included for the purpose of providing peripheral functions to the emulation, such as high-speed multiplexed data communication between the emulator/accelerator and a host workstation.
The chief advantage of including an emulator is that it can perform the concurrent operations in parallel with the sequential operations performed by the workstation to which it is connected. In some cases, an emulator can be interfaced to target hardware. Such hardware may comprise a portion of the system that is being tested or otherwise evaluated. For example, the target hardware may be a personal computer in which a microprocessor has been removed and replaced with cables connecting it to the emulator.
Emulator systems may include one or more behavior cards for performing the sequential operations, thereby taking that portion of the load off the workstation. The behavior card can apply test vectors or model sequential devices, e.g., a memory. Thus, the emulator performs the concurrent operations while the behavior card performs the sequential operations. The two preferably operate in parallel. Nevertheless, the two do not operate asynchronously with respect to each other. Rather, attempts are made to synchronize them with each other by operating in lock-step fashion, i.e., a handshake. On each cycle of the emulation, the emulator produces a “STEP” or “BEGIN_CYCLE” signal. In response to this signal, the behavior card generates a “HALT” signal, which indicates that the behavior card has begun processing data it received from the emulator on the previous cycle and needs the emulator to wait until it has finished doing so. When it has finished, the behavior card drops the HALT signal. In response to the HALT signal being dropped, the emulator can reassert the STEP signal when it is ready to begin another emulation cycle. In addition, if the behavior card asserts the HALT signal but detects an error condition, requires more input data before it can continue, or otherwise needs to suspend the emulation, it can assert a “STOPPED” signal. This signal provides an indication of such a condition to the workstation and to any other behavior cards in the system.
While such timing and hardware implementations have improved the processing times of simulation environments, there remain improvements that can be made to emulation systems. For instance, the communication of bit values between an emulator and a behavior card during a processing cycle conventionally requires a wire to be dedicated to each bit value. The thousands of bit values potentially implicated in an emulation cycle can translate into thousands of wires bundled into hundreds or thousands of cables. These cables, in turn, require a large number of ports to accommodate the cable connections. This multitude of cables and ports can dramatically raise implementation costs, financially burdening developers and dissuading users from realizing the benefits of emulation techniques. There is consequently a need for an improved manner of emulating a hardware design that addresses the above identified problems.